Windows Server ソフトウェア定義ネットワークスタックのトラブルシューティング

適用対象: Supported versions of Windows Server

このガイドでは、ソフトウェア定義ネットワーク (SDN) の一般的なエラーとエラーのシナリオについて説明し、使用可能な診断ツールを使用するトラブルシューティングワークフローの概要を説明します。 SDN の詳細については、「ソフトウェア定義ネットワーク」を参照してください。

適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、および Azure Stack HCI バージョン 21H2 および 20H2

エラーの種類

次の一覧は、Windows Server 2012 R2 の Hyper-V Network Virtualization (HNVv1) で一般的に見られる一般的な問題のクラスを示しています。これは、Windows Server 2016 HNVv2 と新しいソフトウェア定義ネットワーク (SDN) スタックで見られるのと同じ種類の問題と多くの点で一致します。

ほとんどのエラーは、小さなクラスセットに分類できます。

無効な構成またはサポートされていない構成

ユーザーが NorthBound API を誤って呼び出すか、無効なポリシーで呼び出します。
ポリシーアプリケーションのエラー

ネットワークコントローラーからのポリシーは、すべての Hyper-V ホスト (ライブマイグレーション後など) で、Hyper-V ホストに配信されなかったか、遅延されたか、最新ではありません。
構成の誤差またはソフトウェアのバグ

データパスの問題によってパケットが破棄されます。
NIC ハードウェア/ドライバーまたはアンダーレイネットワークファブリックに関連する外部エラー

不適切な動作のタスクオフロード (VMQ など) またはアンダーレイネットワークファブリックが正しく構成されていない (MTU など)

このトラブルシューティングガイドでは、これらの各エラーカテゴリを調べ、エラーの特定と修正に使用できるベストプラクティスと診断ツールを推奨します。

診断ツール

これらの種類のエラーごとにトラブルシューティングワークフローについて説明する前に、使用可能な診断ツールを調べてみましょう。

ネットワークコントローラー (制御パス) 診断ツールを使用するには、最初に RSAT-NetworkController 機能をインストールし、 NetworkControllerDiagnostics モジュールをインポートする必要があります。

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

HNV 診断 (データパス) 診断ツールを使用するには、 HNVDiagnostics モジュールをインポートする必要があります。

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

ネットワークコントローラーの診断

これらのコマンドレットは、ネットワークコントローラー診断コマンドレットの TechNet に記載されています。ネットワークコントローラーノード間、およびネットワークコントローラーと、Hyper-V ホストで実行されている NC ホストエージェント間の制御パスのネットワークポリシー整合性に関する問題を特定するのに役立ちます。

Debug-ServiceFabricNodeStatusおよびGet-NetworkControllerReplicaコマンドレットは、ネットワークコントローラーノードの仮想マシンのいずれかから実行する必要があります。他のすべての NC 診断コマンドレットは、ネットワークコントローラーへの接続を持ち、ネットワークコントローラー管理セキュリティグループ (Kerberos) 内にある、またはネットワークコントローラーを管理するための X.509 証明書にアクセスできる任意のホストから実行できます。

Hyper-V ホスト診断

これらのコマンドレットは、 Hyper-V Network Virtualization (HNV) Diagnostics コマンドレットの TechNet に記載されています。テナント仮想マシン (東部/西部) と SLB VIP (南北) 経由のイングレストラフィックの間のデータパスの問題を特定するのに役立ちます。

Debug-VirtualMachineQueueOperation、Get-CustomerRoute、Get-PACAMapping、Get-ProviderAddress、Get-VMNetworkAdapterPortId、Get-VMSwitchExternalPortId、Test-EncapOverheadSettingsはすべて、任意の Hyper-V ホストから実行できるローカルテストです。他のコマンドレットは、ネットワークコントローラーを介してデータパステストを呼び出すため、前述のようにネットワークコントローラーにアクセスする必要があります。

GitHub

Microsoft/SDN GitHub リポジトリには、これらのインボックスコマンドレットに基づいて構築された多くのサンプルスクリプトとワークフローがあります。特に、診断スクリプトは診断フォルダーにあります。 Pull Requests を送信して、これらのスクリプトに投稿する方法について説明します。

ワークフローとガイドのトラブルシューティング

[Hoster]システムの正常性を検証する

いくつかのネットワークコントローラーリソースには 、Configuration State という名前の埋め込みリソースがあります。構成状態は、ネットワークコントローラーの構成と、Hyper-V ホスト上の実際の (実行中の) 状態の整合性など、システムの正常性に関する情報を提供します。

構成状態を確認するには、ネットワークコントローラーに接続されている任意の Hyper-V ホストから次のコマンドレットを実行します。

注

NetworkController パラメーターの値は、ネットワークコントローラー用に作成された X.509 >certificate のサブジェクト名に基づく FQDN または IP アドレスである必要があります。

Credential パラメーターは、ネットワークコントローラーが Kerberos 認証を使用している場合にのみ指定する必要があります (VMM 展開で一般的)。資格情報は、ネットワークコントローラー管理セキュリティグループ内のユーザーに対する資格情報である必要があります。

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

構成状態メッセージは、次の例のようになります。

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

注

SLB 多重化トランジット VM NIC のネットワークインターフェイスリソースが、"仮想スイッチ - ホストがコントローラーに接続されていません" というエラーでエラー状態になっているシステムにバグがあります。 VM NIC リソースの IP 構成がトランジット論理ネットワークの IP プールの IP アドレスに設定されている場合、このエラーは無視しても問題ありません。

ゲートウェイ HNV プロバイダー VM NIC のネットワークインターフェイスリソースが"仮想スイッチ - PortBlocked" というエラーでエラー状態になっているシステムに 2 つ目のバグがあります。 VM NIC リソースの IP 構成が (仕様により) null に設定されている場合、このエラーは無視しても問題ありません。

次の表に、観察された構成状態に基づいて実行するエラーコード、メッセージ、およびフォローアップアクションの一覧を示します。

Code	メッセージ	アクション
Unknown	不明なエラー
ホスト到達不能	ホストコンピューターに到達できない	ネットワークコントローラーとホストの間の管理ネットワーク接続を確認する
PAIPアドレス枯渇	PA IP アドレスが使い果たされました	HNV プロバイダーの論理サブネットの IP プールサイズを増やす
PA MACアドレスの枯渇	PA Mac アドレスが使い果たされました	Mac プールの範囲を増やす
PAアドレス構成失敗	PA アドレスをホストに接続できませんでした	ネットワークコントローラーとホストの間の管理ネットワーク接続を確認します。
証明書が信頼されていません	証明書が信頼されていない	ホストとの通信に使用される証明書を修正します。
証明書が認可されていません	証明書が承認されていません	ホストとの通信に使用される証明書を修正します。
Vfpでのポリシー構成の失敗	VFP ポリシーの構成の失敗	これはランタイムエラーです。明確な回避策はありません。ログを収集します。
ポリシー設定失敗	NetworkController の通信エラーまたはその他のエラーが原因で、ポリシーをホストにプッシュできない。	明確なアクションはありません。これは、ネットワークコントローラーモジュールでの目標状態処理の失敗が原因です。ログを収集します。
ホストがコントローラに接続されていません	ホストがまだネットワークコントローラーに接続されていません	ポートプロファイルがホストに適用されていないか、ホストがネットワークコントローラーから到達できません。 HostID レジストリキーがサーバーリソースのインスタンス ID と一致することを検証します。
複数のVfpが有効なスイッチ	ホスト上に複数の VFp 対応スイッチがあります	ネットワークコントローラーホストエージェントは VFP 拡張機能を有効にした vSwitch を 1 つだけサポートしているため、いずれかのスイッチを削除します。
ポリシー設定エラー	証明書エラーまたは接続エラーが原因で VmNic の VNet ポリシーをプッシュできませんでした	適切な証明書が展開されているかどうかを確認します (証明書のサブジェクト名がホストの FQDN と一致している必要があります)。また、ネットワークコントローラーとのホスト接続も確認します。
ポリシー構成失敗	証明書エラーまたは接続エラーが原因で VmNic の vSwitch ポリシーをプッシュできませんでした	適切な証明書が展開されているかどうかを確認します (証明書のサブジェクト名がホストの FQDN と一致している必要があります)。また、ネットワークコントローラーとのホスト接続も確認します。
ポリシー構成失敗	証明書エラーまたは接続エラーが原因で VmNic のファイアウォールポリシーをプッシュできませんでした	適切な証明書が展開されているかどうかを確認します (証明書のサブジェクト名がホストの FQDN と一致している必要があります)。また、ネットワークコントローラーとのホスト接続も確認します。
分散ルーター構成失敗	ホスト vNic で分散ルーターの設定を構成できませんでした	TCPIP スタックエラー。このエラーが報告されたサーバー上の PA および DR ホスト vNIC のクリーンアップが必要になる場合があります。
DHCPアドレス割り当て失敗	VMNic の DHCP アドレスの割り当てに失敗しました	静的 IP アドレス属性が NIC リソースで構成されているかどうかを確認します。
証明書が信頼されていません証明書が認可されていません	ネットワークエラーまたは証明書エラーが原因でMuxに接続できませんでした	エラーメッセージコードで指定された数値コードを確認します。これは winsock エラーコードに対応します。証明書エラーは詳細です (たとえば、証明書を検証できない、証明書が承認されていないなど)。
ホスト到達不能	MUX が異常です (一般的なケースは BGPRouter が切断されています)	RRAS (BGP 仮想マシン) または Top-of-Rack (ToR) スイッチの BGP ピアに到達できないか、ピアリングに成功していません。ソフトウェアロードバランサーマルチプレクサーリソースと BGP ピア (ToR または RRAS 仮想マシン) の両方で BGP 設定を確認します。
ホストがコントローラに接続されていません	SLB ホストエージェントが接続されていません	SLB ホストエージェントサービスが実行されていることを確認します。 SLB ホストエージェントのログ (自動実行) を参照して、SLBM (NC) がホストエージェントによって提示された証明書を拒否した理由について確認してください。その実行状態は詳細な情報を示します。
ポートがブロックされました	VNET/ACL ポリシーがないため、VFP ポートがブロックされる	他のエラーが発生しているかどうかを確認します。これにより、ポリシーが構成されていない可能性があります。
過負荷	ロードバランサーの MUX がオーバーロードされている	MUX のパフォーマンスの問題。
経路公開失敗	ロードバランサーの MUX が BGP ルーターに接続されていない	MUX に BGP ルーターとの接続があり、BGP ピアリングが正しく設定されているかどうかを確認します。
バーチャルサーバーに到達できません	ロードバランサーの MUX が SLB マネージャーに接続されていない	SLBM と MUX の間の接続を確認します。
QoS設定失敗 (QosConfigurationFailure)	QOS ポリシーの構成に失敗しました	QOS 予約が使用されている場合は、すべての VM で十分な帯域幅を使用できるかどうかを確認します。

ネットワークコントローラーと Hyper-V Host (NC ホストエージェントサービス) の間のネットワーク接続を確認する

次の netstat コマンドを実行して、NC ホストエージェントとネットワークコントローラーノードの間に 3 つの ESTABLISHED 接続があり、Hyper-V ホスト上に 1 つの LISTENING ソケットがあることを検証します。

TCP ポート 6640 でリッスン中: Hyper-V ホスト上の NC ホストエージェントサービス
Hyper-V ホストのIPアドレスからポート6640を通じて、エフェメラルポート（> 32000）でのNCノードのIPアドレスへの2つの確立された接続。
Hyper-V ホスト IP の一時的なポートからポート 6640 のネットワークコントローラー REST IP への確立された接続が 1 つありました。

注

その特定のホストにテナント仮想マシンがデプロイされていない場合、Hyper-V ホストに確立された接続は 2 つしかない可能性があります。

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

ホストエージェントサービスを確認する

ネットワークコントローラーは、Hyper-V ホスト上の 2 つのホストエージェントサービス (SLB ホストエージェントと NC ホストエージェント) と通信します。これらのサービスの一方または両方が実行されていない可能性があります。状態を確認し、実行されていない場合は再起動します。

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

ネットワークコントローラーの正常性を確認する

ESTABLISHED接続が 3 つない場合、またはネットワークコントローラーが応答していないように見える場合は、次のコマンドレットを使用して、すべてのノードとサービスモジュールが稼働していることを確認します。

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

ネットワークコントローラーサービスモジュールは次のとおりです。

ControllerService
ApiService
SlbManagerService
ServiceInsertion
FirewallService
VSwitchService
GatewayManager
FnmService
HelperService
UpdateService

ReplicaStatusがReadyであり、HealthStateがOkされていることを確認します。

運用デプロイでは、マルチノードネットワークコントローラーを使用して、各サービスがプライマリになっているノードとその個々のレプリカの状態を確認することもできます。

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

各サービスのレプリカの状態が準備ができていることを確認します。

ネットワークコントローラーと各 Hyper-V ホスト間の対応する HostID と証明書を確認する

Hyper-V ホストで、次のコマンドレットを実行して、HostID がネットワークコントローラー上のサーバーリソースのインスタンス ID に対応していることを確認します

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1
Properties       : Microsoft.Windows.NetworkController.ServerProperties

修復

SDNExpress スクリプトまたは手動デプロイを使用する場合は、サーバーリソースのインスタンス ID と一致するようにレジストリの HostId キーを更新します。 Hyper-V ホスト (物理サーバー) でネットワークコントローラーホストエージェントを再起動します。VMM を使用している場合は、VMM から Hyper-V サーバーを削除し、HostId レジストリキーを削除します。次に、VMM を使用してサーバーをもう一度追加します。

Hyper-V ホスト (NC ホストエージェントサービス) とネットワークコントローラーノード間の (SouthBound) 通信のために、Hyper-V ホスト (ホスト名は証明書のサブジェクト名) によって使用される X.509 証明書の拇印が同じであることを確認します。また、ネットワークコントローラーの REST 証明書のサブジェクト名が CN=<FQDN or IP> であることを確認します。

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

また、各証明書の次のパラメーターを確認して、サブジェクト名が予期される内容 (ホスト名または NC REST FQDN または IP)、証明書の有効期限がまだ切れていない、および証明書チェーン内のすべての証明機関が信頼されたルート機関に含まれていることを確認することもできます。

サブジェクト名
有効期限
ルート機関によって信頼される

Hyper-V ホスト上で複数の証明書のサブジェクト名が同じである場合、ネットワークコントローラーホストエージェントは、ネットワークコントローラーに提示する証明書をランダムに選択します。これは、ネットワークコントローラーに認識されているサーバーリソースの拇印と一致しない可能性があります。この場合は、Hyper-V ホストで同じサブジェクト名を持つ証明書の 1 つを削除し、ネットワークコントローラーホストエージェントサービスを再起動します。まだ接続できない場合は、Hyper-V ホストで同じサブジェクト名を持つ他の証明書を削除し、VMM で対応するサーバーリソースを削除します。次に、VMM でサーバーリソースを再作成します。これにより、新しい X.509 証明書が生成され、Hyper-V ホストにインストールされます。

SLB 構成の状態を確認する

SLB 構成状態は、 Debug-NetworkController コマンドレットへの出力の一部として決定できます。また、このコマンドレットは、JSON ファイル内のネットワークコントローラーリソースの現在のセット、各 Hyper-V ホスト (サーバー) のすべての IP 構成、および Host Agent データベーステーブルからのローカルネットワークポリシーも一覧表示します。

既定では、mMore トレースが収集されます。トレースを収集しない場合は、 -IncludeTraces:$false パラメーターを追加します。

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

注

既定の出力場所は、 <working_directory>\NCDiagnostics\ ディレクトリです。既定の出力ディレクトリは、 -OutputDirectory パラメーターを使用して変更できます。

SLB 構成状態の情報は、このディレクトリの diagnostics-slbstateResults.Json ファイルにあります。

この JSON ファイルは、次のセクションに分けることができます。

生地
- SlbmVips - このセクションでは、SLB マネージャー VIP アドレスの IP アドレスを示します。これは、SLB Muxes と SLB ホストエージェント間の構成と正常性を調整するためにネットワークコントローラーによって使用されます。
- MuxState - このセクションでは、展開された各 SLB Mux の状態に対して 1 つの値を一覧表示します。
- ルーターの構成 - このセクションでは、アップストリームルーター (BGP ピア) 自律システム番号 (ASN)、トランジット IP アドレス、および ID を一覧表示します。また、SLB マルチプレクサ ASN とトランジット IP も一覧表示されます。
- 接続ホスト情報 - このセクションでは、負荷分散されたワークロードを実行するために使用できるすべての Hyper-V ホストの管理 IP アドレスを示します。
- Vip 範囲 - このセクションでは、パブリックおよびプライベート VIP IP プールの範囲の一覧を示します。 SLBM VIP は、これらの範囲のいずれかから割り当てられた IP として含まれます。
- 多重化ルート - このセクションでは、その特定の多重化のすべてのルートアドバタイズを含む、展開された各 SLB Mux に対して 1 つの値を一覧表示します。
テナント
- VipConsolidatedState - このセクションでは、アドバタイズされたルートプレフィックス、Hyper-V ホスト、DIP エンドポイントなど、各テナント VIP の接続状態を一覧表示します。

注

SLB 状態は、Microsoft SDN GitHub リポジトリで使用可能な DumpSlbRestState スクリプトを使用して直接確認できます。

ゲートウェイの検証

ネットワークコントローラーから:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

ゲートウェイ VM から:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

トップ・オブ・ラック (ToR) スイッチから:

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP ルーター:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

これらに加えて、これまでに見てきた問題 (特に SDNExpress ベースのデプロイ) から、GW VM でテナントコンパートメントが構成されない最も一般的な理由は、FabricConfig.psd1 の GW 容量が TenantConfig.psd1 のネットワーク接続 (S2S トンネル) に割り当てようとする場合と比べて低いようです。これは、次のコマンドレットの出力を比較することで簡単に確認できます。

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster] Data-Plane を検証する

ネットワークコントローラーがデプロイされ、テナント仮想ネットワークとサブネットが作成され、VM が仮想サブネットにアタッチされた後、ホスト側は、さらにファブリックレベルのテストを実行してテナントの接続を確認できます。

HNV プロバイダーの論理ネットワーク接続を確認する

Hyper-V ホストで実行されている最初のゲスト VM がテナント仮想ネットワークに接続されると、ネットワークコントローラーは 2 つの HNV プロバイダー IP アドレス (PA IP アドレス) を Hyper-V ホストに割り当てます。これらの IP は、HNV プロバイダーの論理ネットワークの IP プールから取得され、ネットワークコントローラーによって管理されます。これら 2 つの HNV IP アドレスを確認するには、次のコマンドレットを実行します。

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

これらの HNV プロバイダー IP アドレス (PA IP) は、別の TCPIP ネットワークコンパートメントで作成されたイーサネットアダプターに割り当てられ、X が HNV プロバイダー (トランスポート) 論理ネットワークに割り当てられた VLAN である VLANX のアダプター名を持ちます。

HNV プロバイダー論理ネットワークを使用する 2 つの Hyper-V ホスト間の接続は、追加のコンパートメント (-c Y) パラメーターを持つ ping によって行うことができます。Y は PAhostVNIC が作成される TCPIP ネットワークコンパートメントです。このコンパートメントを確認するには、Windows コマンドプロンプトで次のコマンドを実行します。

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

注

PA ホスト vNIC アダプターはデータパスでは使用されないため、vEthernet (PAhostVNic) アダプターに IP が割り当てられていません。

たとえば、Hyper-V ホスト 1 とホスト 2 には、次の HNV プロバイダー (PA) IP アドレスがあるとします。

Hyper-V ホスト	PA IP アドレス 1	PA IP アドレス 2
ホスト 1	10.10.182.64	10.10.182.65
ホスト 2	10.10.182.66	10.10.182.67

次のコマンドを使用して 2 つの間で ping を実行して、HNV プロバイダーの論理ネットワーク接続を確認できます。

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

修復

HNV プロバイダーの ping が機能しない場合は、VLAN 構成を含む物理ネットワーク接続を確認します。各 Hyper-V ホスト上の物理 NIC は、特定の VLAN が割り当てられていないトランクモードである必要があります。管理ホスト vNIC は、管理論理ネットワークの VLAN に分離する必要があります。

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

HNV プロバイダー論理ネットワークで MTU とジャンボフレームのサポートを確認する

HNV プロバイダー論理ネットワークのもう 1 つの一般的な問題は、物理ネットワークポートやイーサネットカードに、VXLAN (または NVGRE) カプセル化のオーバーヘッドを処理するための十分な大きさの MTU が構成されていないことです。

注

一部のイーサネットカードとドライバーは、ネットワークコントローラーホストエージェントが自動的に 160 の値に設定する新しい *EncapOverhead キーワードをサポートしています。この値は、広告されたMTUの合計として使用される*JumboPacketキーワードの価値に追加されます。

たとえば、 *EncapOverhead = 160、 *JumboPacket = 1514 = > MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

HNV プロバイダーの論理ネットワークで、より大きな MTU サイズのエンドツーエンドがサポートされているかどうかをテストするには、 Test-LogicalNetworkSupportsJumboPacket コマンドレットを使用します。

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

修復

物理スイッチポートの MTU サイズを少なくとも 1674B に調整します (14B イーサネットヘッダーとトレーラーを含む)
NIC カードで EncapOverhead キーワードがサポートされていない場合は、JumboPacket キーワードを 1674B 以上に調整します

テナント VM の NIC 接続を確認する

ゲスト VM に割り当てられた各 VM NIC には、プライベートカスタマーアドレス (CA) と HNV プロバイダーアドレス (PA) 領域の間の CA-PA マッピングがあります。これらのマッピングは、各 Hyper-V ホストの OVSDB サーバーテーブルに保持され、次のコマンドレットを実行して見つけることができます。

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

注

予想される CA-PA マッピングが特定のテナント VM に対して出力されない場合は、 Get-NetworkControllerNetworkInterface コマンドレットを使用して、ネットワークコントローラー上の VM NIC と IP 構成リソースを確認します。また、NC ホストエージェントとネットワークコントローラーノードの間に確立された接続を確認します。

この情報を使用して、Hoster は、 Test-VirtualNetworkConnection コマンドレットを使用して、ネットワークコントローラーからテナント VM ping を開始できます。

特定のトラブルシューティングシナリオ

次のセクションでは、特定のシナリオのトラブルシューティングに関するガイダンスを提供します。

2 つのテナント仮想マシン間にネットワーク接続がない

[テナント]テナント仮想マシンの Windows ファイアウォールがトラフィックをブロックしていないことを確認します。
[テナント] ipconfigを実行して、テナント仮想マシンへの IP アドレスがあることを確認します。
[Hoster]Hyper-V ホストから Test-VirtualNetworkConnection を実行して、対象の 2 つのテナント仮想マシン間の接続を検証します。

注

VSID は仮想サブネット ID を参照します。 VXLAN の場合、これは VXLAN ネットワーク識別子 (VNI) です。この値は、 Get-PACAMapping コマンドレットを実行することで確認できます。

Example

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

ホスト "sa18n30-2.sa18.nttest.microsoft.com" の SenderCA IP が 192.168.1.4 の "Green Web VM 1" の間に CA ping を作成し、Mgmt IP は 10.127.132.153 で、ListenerCA IP は 192.168.1.5 の両方が仮想サブネット (VSID) 4114 に接続されます。

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[テナント]仮想サブネットまたは VM ネットワークインターフェイスで、トラフィックをブロックする分散ファイアウォールポリシーが指定されていないことを確認します。

sa18.nttest.microsoft.com ドメインの sa18n30nc のデモ環境にあるネットワークコントローラー REST API に対してクエリを実行します。

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

この ACL を参照している IP 構成と仮想サブネットを確認する

[Hoster]対象の 2 つのテナント仮想マシンをホストする両方の Hyper-V ホストで Get-ProviderAddress を実行します。次に、HNV プロバイダー論理ネットワーク上の接続を検証するには、 Test-LogicalNetworkConnection を実行するか、Hyper-V ホストから ping -c <compartment> します。
[Hoster]Hyper-V ホストと、Hyper-V ホスト間のレイヤ 2 スイッチングデバイスで MTU 設定が正しいことを確認します。対象のすべての Hyper-V ホストで Test-EncapOverheadValue を実行します。また、160 バイトの最大オーバーヘッドを考慮して、その間のすべてのレイヤー 2 スイッチで MTU が 1,674 バイト以上に設定されていることを確認します。
[Hoster]PA IP アドレスが存在しない場合や CA 接続が切断されている場合は、ネットワークポリシーが受信されていることを確認します。 Get-PACAMappingを実行して、オーバーレイ仮想ネットワークの作成に必要なカプセル化規則と CA-PA マッピングが正しく確立されているかどうかを確認します。
[Hoster]ネットワークコントローラーホストエージェントがネットワークコントローラーに接続されていることを確認します。これを行うには、netstat -anp tcp |findstr 6640 を実行します。
[Hoster]HKLM/ のホスト ID が、テナント仮想マシンをホストしているサーバーリソースのインスタンス ID と一致することを確認します。
[Hoster]ポートプロファイル ID がテナント仮想マシンの VM ネットワークインターフェイスのインスタンス ID と一致することを確認します。

ログ記録、トレース、および高度な診断

次のセクションでは、高度な診断、ログ記録、トレースについて説明します。

ネットワークコントローラーの一元的なログ記録

ネットワークコントローラーは、デバッガーログを自動的に収集し、一元化された場所に格納できます。ネットワークコントローラーを初めてデプロイするとき、または後でいつでも、ログ収集を有効にすることができます。ログはネットワークコントローラーから収集され、ネットワークコントローラーによって管理されるネットワーク要素 (ホストマシン、ソフトウェアロードバランサー (SLB)、ゲートウェイマシン) が収集されます。

これらのログには、ネットワークコントローラークラスター、ネットワークコントローラーアプリケーション、ゲートウェイログ、SLB、仮想ネットワーク、分散ファイアウォールのデバッグログが含まれます。新しいホスト/SLB/ゲートウェイがネットワークコントローラーに追加されるたびに、それらのマシンでログ記録が開始されます。同様に、ホスト/SLB/ゲートウェイがネットワークコントローラーから削除されると、それらのマシンでログ記録が停止します。

ログ記録を有効にする

Install-NetworkControllerCluster コマンドレットを使用してネットワークコントローラークラスターをインストールすると、ログ記録が自動的に有効になります。既定では、%systemdrive% \SDNDiagnostics のネットワークコントローラーノードでログがローカルに収集されます。この場所は、(ローカルではなく) リモートファイル共有に変更することをお勧めします。

ネットワークコントローラークラスターログは、 %programData%\Windows Fabric\log\Traces に格納されます。 DiagnosticLogLocation パラメーターを使用して、ログ収集の一元化された場所を指定できます。この場所もリモートファイル共有である必要があります。

この場所へのアクセスを制限する場合は、 LogLocationCredential パラメーターを使用してアクセス資格情報を指定できます。ログの場所にアクセスするための資格情報を指定する場合は、 CredentialEncryptionCertificate パラメーターも指定する必要があります。これは、ネットワークコントローラーノードにローカルに格納されている資格情報を暗号化するために使用されます。

既定の設定では、中央の場所に少なくとも 75 GB の空き領域があり、3 ノードのネットワークコントローラークラスターのローカルノード (中央の場所を使用していない場合) には 25 GB の空き領域を用意することをお勧めします。

ログ設定を変更する

Set-NetworkControllerDiagnostic コマンドレットを使用すると、いつでもログ設定を変更できます。次の設定を変更できます。

一元化されたログの場所。

DiagnosticLogLocation パラメーターを使用して、すべてのログを格納する場所を変更できます。
ログの場所にアクセスするための資格情報。

LogLocationCredential パラメーターを使用して、資格情報を変更してログの場所にアクセスできます。
ローカルログに移動します。

ログを格納するための一元的な場所を指定した場合は、 UseLocalLogLocation パラメーターを使用してネットワークコントローラーノードのローカルログに戻すことができます (ディスク領域の要件が大きいため、推奨されません)。
ログスコープ。

既定では、すべてのログが収集されます。ネットワークコントローラークラスターログのみを収集するようにスコープを変更できます。
ログレベル。

既定のログ記録レベルは Informational です。これを [エラー]、[警告]、または [詳細] に変更できます。
ログのエージング時間。

ログは循環形式で格納されます。ローカルログを使用するか、一元的なログ記録を使用するかに関係なく、既定では 3 日間のログデータがあります。この制限時間は、 LogTimeLimitInDays パラメーターで変更できます。
ログのエージングサイズ。

既定では、集中ログを使用する場合は最大 75 GB のログデータが、ローカルログを使用する場合は 25 GB になります。この制限は、 LogSizeLimitInMBs パラメーターで変更できます。

ログとトレースの収集

VMM 展開では、ネットワークコントローラーの一元的なログが既定で使用されます。これらのログのファイル共有の場所は、ネットワークコントローラーサービステンプレートのデプロイ時に指定されます。

ファイルの場所を指定しない場合、各ネットワークコントローラーノードはログをローカルに保存します。各ノードは 、C:\Windows\tracing\SDNDiagnostics の下にログを保存します。これらのログは、次の階層を使用して保存されます。

クラッシュダンプ
NCApplicationCrashDumps
NCアプリケーションログ
PerfCounters
SDNDiagnostics
痕跡

ネットワークコントローラーは (Azure) Service Fabric を使用します。特定の問題のトラブルシューティングを行うときは、Service Fabric ログが必要になる場合があります。これらのログは、 C:\ProgramData\Microsoft\Service Fabric の各ネットワークコントローラーノードにあります。

ユーザーが Debug-NetworkController コマンドレットを実行した場合、ネットワークコントローラーのサーバーリソースで指定されている各 Hyper-V ホストで、さらに多くのログを使用できるようになります。これらのログ (および有効な場合はトレース) は C:\NCDiagnostics の下に保持されます。

SLB 診断

SLBM ファブリックエラー (ホスティングサービスプロバイダーアクション)

ソフトウェアロードバランサーマネージャー (SLBM) が機能していること、およびオーケストレーションレイヤーが相互に通信できることを確認します。SLBM -> SLB Mux と SLBM -> SLB ホストエージェント。ネットワークコントローラー REST エンドポイントにアクセスできる任意のノードから DumpSlbRestState を実行します。
ネットワークコントローラーノード VM の 1 つ (できればプライマリネットワークコントローラーノード - Get-NetworkControllerReplica) で PerfMon の SDNSLBMPerfCounters を検証します。
1. ロードバランサー (LB) エンジンは SLBM に接続されていますか? (SLBM LBエンジン構成合計 > 0)
2. SLBM は、少なくとも独自のエンドポイントについて知っていますか? (VIP エンドポイントの合計>= 2)
3. Hyper-V (DIP) ホストは SLBM に接続されていますか? (HP クライアント数接続 == サーバー数)
4. SLBM はマルチプレクサに接続されていますか? (接続済みマックス == SLBM上の健全マックス == 健全報告マックス = #SLBマックスVM)。
構成されている BGP ルーターが SLB MUX と正常にピアリングされていることを確認します。
1. リモートアクセス (つまり、BGP 仮想マシン) で RRAS を使用する場合:
  1. Get-BgpPeer 接続済みと表示されます。
  2. Get-BgpRouteInformation は、SLBM セルフ VIP のルートを少なくとも表示する必要があります。
2. BGP ピアとして物理 Top-of-Rack (ToR) スイッチを使用する場合は、ドキュメントを参照してください。
  1. 例: # show bgp instance
SLB 多重化 VM 上の PerfMon で SlbMuxPerfCounters および SLBMUX のカウンターを検証します。
ソフトウェアロードバランサーマネージャーリソースの構成状態と VIP 範囲を確認します。
1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (IP プールの VIP 範囲を確認し、SLBM セルフ VIP (LoadBalanacerManagerIPAddress) とテナント側 VIP がこれらの範囲内にあることを確認します)
  1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
2. Debug-NetworkControllerConfigurationState -

上記のいずれかのチェックが失敗した場合、テナントの SLB 状態もエラーモードになります。

修復

表示される次の診断情報に基づいて、次の問題を修正します。

SLB マルチプレクサーが接続されていることを確認する
- 証明書の問題を修正する
- ネットワーク接続の問題を修正する
BGP ピアリング情報が正常に構成されていることを確認する
レジストリのホスト ID がサーバーリソースのサーバーインスタンス ID と一致していることを確認します ( HostNotConnected エラーコードの付録を参照)
ログの収集

SLBM テナントエラー (ホスティングサービスプロバイダーとテナントアクション)

[Hoster] Debug-NetworkControllerConfigurationState チェックして、LoadBalancer リソースがエラー状態であるかどうかを確認します。付録のアクション項目の表に従って、軽減を試みます。
1. VIP エンドポイントとアドバタイズルートが存在することを確認します。
2. VIP エンドポイントで検出された DIP エンドポイントの数を確認します。
[テナント]Load Balancer リソースが正しく指定されていることを検証します。
1. SLBM に登録されている DIP エンドポイントが、LoadBalancer バックエンドアドレスプールの IP 構成に対応するテナント仮想マシンをホストしていることを検証します。
[Hoster]DIP エンドポイントが検出または接続されていない場合:
1. Debug-NetworkControllerConfigurationState を確認する
  
  netstat -anp tcp |findstr 6640)を使用して、NC および SLB ホストエージェントがネットワークコントローラーイベントコーディネーターに正常に接続されていることを検証します。
2. サービスの regkeyHostIdnchostagentを確認します (付録のエラーコードHostNotConnectedを参照)。これが対応するサーバーリソースのインスタンス ID (Get-NCServer |convertto-json -depth 8) と一致します。
3. 仮想マシンのポートのポートプロファイル ID が、対応する仮想マシン NIC リソースのインスタンス ID と一致するかどうかを確認します。
[ホスティングプロバイダー]ログを収集します。

SLB 多重化トレース

ソフトウェアロードバランサーのマルチプレクサからの情報は、イベントビューアーを使用して決定することもできます。

[イベントビューアー ビュー] メニューの [分析ログとデバッグログの表示] を選択します。
イベントビューアーで アプリケーションとサービスログ>Microsoft>Windows>SlbMuxDriver>Trace に移動します。
右クリックし、[ログの 有効化] を選択します。

注

問題を再現しようとしている間は、このログ記録を短時間だけ有効にすることをお勧めします。

VFP と vSwitch のトレース

テナント仮想ネットワークに接続されているゲスト VM をホストしている任意の Hyper-V ホストから、VFP トレースを収集して、問題が発生する可能性がある場所を特定できます。

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-17